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Abstract 

Accurate knowledge and understanding of data link 
traffic loads that will have an impact on the underlying 
communications infrastructure within the National 
Airspace System (NAS) is of paramount importance for 
planning, development and fielding of future airborne and 
ground-based communications systems. Currently, this 
problem is not well understood, and to make accurate 
assessment of the impact that data link traffic loads will 
impose on the NAS requires testing and verification of the 
characteristics and performance of the Communications, 
Navigation, and Surveillance (CNS) technologies to be 
developed and deployed in the future airspace 
environment. Attempting to better understand this impact, 
NASA Glenn Research Center (GRC), through its 
contractor Computer Networks & Software, Inc. (CNS, 
Inc.), has developed an emulation and test facility known 
as “the Virtual Aircraft and Controller (VAC)” to study 
data link interactions and the capacity of the NAS to 
support Controller Pilot Data Link Communications 
(CPDLC) traffic. The drawback of the current VAC test 
bed is that it does not allow the test personnel and 
researchers to present a real world RF environment to a 
complex airborne or ground system. Thus, the impact of 
the varying modulations, antenna equipage, and radio 
frequency usage upon data link communication cannot be 
realistically tested and verified. 

Fortunately, the United States Air Force and Navy 
Avionics Test Commands, through its contractor ViaSat, 
Inc., have developed the Joint Communications Simulator 
(JCS) to provide communications band test and simulation 
capability for the RF spectrum through 1 8 GHz including 
Communications, Navigation, and Identification and 
Surveillance functions. 

In this paper, we are proposing the development of a 
new and robust test bed that will leverage on the existing 
NASA GRC’s VAC and the Air Force and Navy 
Commands’ JCS systems capabilities and functionalities. 
The proposed NASA Glenn Research Center’s 
Aeronautical Networks Research Simulator (ANRS) will 
combine current Air Traffic Control applications and 


physical RF stimulation into an integrated system capable 
of emulating data transmission behaviors including 
propagation delay, physical protocol delay, transmission 
failure and channel interference. The ANRS will provide 
a simulation/stimulation tool and test bed environment 
that allow the researcher to predict the performance of 
various aeronautical network protocol standards and their 
associated waveforms under varying density conditions. 
The system allows the user to define human-interactive 
and scripted aircraft and controller models of various 
standards, such as (but not limited to) Very High 
Frequency Digital Link (VDL) of various modes. The 
system also provides a complete RF environment 
including voice communications, surveillance radars, and 
airport navigation and landing systems. Additionally, co- 
site or noise is generated including television stations, cell 
networks, signal multi-path and reflections, all providing 
the backdrop for a real-world RF environment. It also 
allows the user to define associated platforms and emitters 
and place these according to flight plans. 

1. Existing System Capabilities 
1.1 VAC Summary 

The VAC software set consists of the following major 
component applications: 

• Human Interactive Aircraft (HIA) 

• Human Interactive Controller (HIC) 

• Autonomous Aircraft (AA) 

• Autonomous Controller (AC) 

• System Manager 

An overview of the VAC System [1] is shown in Figure 1. 

The VAC system is composed of software 
applications (the Applications) that interface with routers 
using the Aeronautical Telecommunications Network 
(ATN) network layer protocol, which is Connectionless 
Network Protocol (CLNP). The routers in turn are 
connected to aircraft and ground-based data link radios. 



The Applications provide a virtual aircraft/controller 
capability that emulates pilot/controller data link 
exchanges for as many as 160 aircraft using script-driven 
events. The Applications generate Context Management 
(CM) and CPDLC messages that are ATN compliant, the 
protocol standard that will be implemented by the Federal 
Aviation Administration (FAA). The CPDLC message set 
includes all the messages in Aeronautical Data Link 
Service (ADLS) Baseline I, which is the set of messages 
to be implemented in the FAA’s CPDLC IA program. The 
Test bed also includes workstations with aircraft and 
controller graphical user interfaces at which users can 
generate and respond to CM and CPDLC messages. 


The Applications provide script-driven and human- 
interactive message emulation. End-to-end CPDLC 
emulation is provided through script-driven, departure- 
through-arrival scenarios that can support a full range of 
communications test activities. A System Manager 
workstation provides configuration control, scenario and 
script selection, experiment management, and data 
reduction and analysis capabilities for the Test bed. 

An upgrade of the VAC software is currently being 
performed. The scope of this upgrade project is to add 
Traffic Information Services - Broadcast (TIS-B) and 
Automatic Dependent Surveillance - Broadcast (ADS-B) 
capabilities to GRC’s existing Virtual Aircraft and 
Controller (VAC) large-scale Aeronautical 
Telecommunications Network (ATN) emulation software 
set. This upgrade includes a significant enhancement in 
real world scenario planning by providing a flight- 
planning tool that is coupled to the messaging scripts. 
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Figure 1. VAC System Overview 




1.2 JCS Summary 

1.2.1 Test Philosophy for JCS 

The development of the Joint Communication 
Simulator [2] was driven by a desire to test many types of 
disparate communications systems using common test 
equipment. Each system being tested would typically 
operate in a real-world RF environment that varies from 
that of other systems in many ways including frequencies, 
bandwidths, modulations, antenna patterns and geographic 
region, to name a few. Each System Under Test (SUT) 
would typically be exposed to some signals that were 
common among the various types of SUTs (e.g. television 
signals, radio signals, ...etc.). Therefore, the JCS was 
designed to be capable of generating many different types 
of communication signals simultaneously. 

Operationally, an SUT might be exposed to a set of 
signals of interest that were dynamic in RF characteristics. 
For example, an SUT might fly into a region around an 
airport that uses secondary surveillance radars and then 
find that it was being interrogated, or it might fly within 
line of sight of a Tactical Air Navigation (TACAN) 
station and periodically receive Morse code identifying 
the airport. In either of these cases the amplitude of the 
pulsed signals would vary with respect to the SUT as the 
transmitting antenna rotated. As another example, an 
SUT could receive voice bursts of command, query and 
status from an air traffic controller. In each of these cases, 
the RF presented to the SUT would vary, not only because 
of the signal modulation, but also because of specific 
system functionality. Therefore, the JCS needed to be 
capable of emulating the functionality of systems that 
generated the signals of interest to the SUT. 

An SUT could be mobile and could communicate 
with other systems that were also mobile. This could 
affect communication between the SUT and other 
platforms in many ways. The relative motion between 
platforms could induce Doppler effects on the received 
signal. Transmit and receive antenna gain characteristics 
could change as the relative position of the SUT and other 
platforms changed. Also, the ability to receive a given 
signal could be affected by the altitude of each platform. 
In other words, the RF environment the SUT would see 
could change with the time varying relative geometry 
between the SUT and the other communicating platforms. 
Therefore, the JCS was designed to be capable of 
calculating platform motion for all of the communicating 


platforms and determining the effects on the RF signals at 
the SUT and virtual receivers. 

Finally, the researcher would want to examine 
conditions that might be difficult, if not impossible, to 
produce in the real world. As an example, supposed an 
SUT’s Mark XII Interrogation system is being tested and 
is not reporting the correct Mode C altitude of a virtual 
transponding aircraft, based upon the aircraft’s true 
altitude within the scenario. The researcher would want to 
have the freedom to change simulation conditions and 
parameters in an effort to determine why this is occurring. 
Manual control of the virtual transponding aircraft could 
be affected to change its altitude, repeatedly noting the 
differences in reported versus actual altitude. (Other 
altitude-related parameters could also be altered, such as 
received signal power at the SUT, to remain constant in an 
effort to change only the virtual aircraft’s reply 
information.) If it were found that the reply information is 
still processed incorrectly, all emitters could be disabled 
in the scenario except the reply from the virtual platform. 
If the SUT then began to correctly track the altitude 
change in the virtual platform, other emitters could be 
enabled, one at a time, until the disrupting signal is 
identified. Many permutations of this illustration are 
possible, and the ability to change individual parameters 
of interest is an extremely useful capability allowing 
researchers to affect scenario parameters and events in 
real time. 


1.2.2 JCS Capabilities and Architecture 

The JCS has been developed with a sharp focus on 
modularity, allowing grouping of hardware as required by 
researchers. The largest JCS systems built to date provide 
programmable RF sources for 92 simultaneous signals. Of 
these, 76 are termed Non-Angle-of-Arrival (Non-AoA) 
RF while the other 16 signal sources are termed AoA. 
The Non-AoA RF sources are meant to feed RF antenna 
inputs of an SUT that are not sensitive to the direction of 
arrival of the signal. Most antennas are of this type. The 
AoA signals are meant to feed SUT RF interferometers 
used for direction finding. The JCS is designed for 
interferometers of up to 32 elements. The Non-AoA signal 
frequency coverage is from 0.5 MHz to 18 GHz, and for 
AoA signals, the frequency coverage is from 20 MHz to 2 
GHz. All signal sources are programmable to vary by 
signal type, bandwidth, signal strength and operating 
frequency. Using these signal sources, the JCS is capable 



of simulating scenarios involving numerous platforms, 
each emitting several different RF CNI signals. The JCS 
can create effects due to relative motion of the System 
Under Test with respect to other simulated platforms 
including path loss, carrier Doppler, antenna directivity 
variations, and AoA amplitude and phasing. 

The JCS signal generators have been designed as field 
programmable gate array-based arbitrary waveform 
generators. These signal generators can produce signals 
of many different modulation types (such as AM, FM, 
SSB, DSB, QPSK, FSK, OQPSK, QAM, PPM). The 
most common mode of operation for the signal generators 
is to receive data because of virtual model 
communications. Developed signal types include Air 
Traffic Control (ATC), Identification Friend or Foe (IFF), 
navigation, and data communication signals. 
Additionally, the signal generators are capable of 
receiving external analog and digital data that they can 
modulate. They can be externally triggered and also can 
supply an output trigger. These signal generators can 
produce digital signals of up to 10 mega-symbols per 
second and pulsed signals with a minimum pulse width of 
25 ns. 


The architecture of the JCS is modular in form and is 
built up from a relatively small number of unique modules 
as illustrated in Figure 2. The JCS architecture consists of 
the following main components: 

• Control Station (CS) 

• Control Station Subsystem (CSS) 

• Signal Generation Units (SGU) 

• Non- AoA RF Data System (NARFDS) 

• AoA RF Data System (ARFDS) 

The Control Station is a SUN Workstation with two 
monitors. The CS presents the JCS Graphical User 
Interface (GUI) to the user. The JCS GUI allows the user 
to construct as well as control a scenario. This GUI allows 
the operator to define emitters, define platforms and 
scenarios, run scenarios, and perform built in test (BIT) 
and calibration functions. Each Signal Generation 
Processor (SGP) within the SGU Subsystem is responsible 
for simulating a subset of the real-world systems being 
emulated by the JCS. The Non-AoA RF Data Processor 
(NARFDP) within the NARFDS is responsible for RF 
attenuation and mixer band control for presentation of the 
waveform to the SUT. Automatic user-initiated 
calibration is performed to ensure the RF accuracy 
including timing, power level and phase of signals 
presented to the SUT. In addition, the JCS contains BIT 
features down to the lowest user replaceable module. The 
calibration and BIT are also accessible via the simulator 
GUI. 




Figure 2. JCS Architecture 



1.3 ANRS Proposal Summary 

Meeting the objectives of a cost effective Virtual RF 
Test Bench Environment requires a modular, scalable 
approach allowing future functions and upgrades to be 
included with minimal risk and minimal cost impacts. The 
architectural approach undertaken to meet the ANRS 
objectives is an outgrowth of architectures previously 
implemented in VAC, JCS and related programs. The 
ANRS architecture [3] will build on the key elements 
from these programs and add updated technology and 
designs to provide CNS performance through 50 GHz. 

In deriving the proposed ANRS architecture, our 
focus was two-fold. First, we desired to leverage existing 
JCS assemblies or Hardware Control Items (HWCIs), and 
subsystem definitions to the greatest extent practical and 
still provide a modular, flexible ANRS solution. Second, 
we were extremely concerned about any architectural 
evolution that would require a re-definition of software 
states and modes, as we believe a large cost impact is 
avoided through the preservation of the JCS software 
functional architecture. 

The Staged approach to build the ANRS test bench 
will utilize development of early test scenarios to ensure 
that adequate system capability is available at each stage 
of development. This allows ANRS to operate from a 
virtual RF environment through hardware-in-the-loop 
testing. At each development stage of the program 
additional hardware, software and systems capability will 
be integrated and demonstrated, providing GRC with a 
continually more capable testing asset for the life of the 
program. 

The modular, scalable nature of the ANRS 
architecture allows new waveforms to be added without 
significant impact to the existing hardware compliment. 
This will minimize the risk of adding future (currently 
undefined) waveforms to the ANRS waveform library. 
This approach will enable the ANRS developer to 
customize and adapt deliveries to specific NASA budget 
and schedule constraints without adding additional risk to 
the development and delivery of the final system 
configuration. 


2. Technical Approach to ANRS 
2.1 Theory of Operation 

The Aeronautical Network Research Simulator is a 
tool that allows the researcher to predict the performance 
of various aeronautical network protocol standards and 
their associated waveforms under varying density and 
environmental conditions. A block diagram showing a 
pushdown view of the critical subfunctions of the ANRS 
is provided in Figure 3. 

The Critical components that comprise the heart of the 
ANRS are the Controller and Aircraft Model and 
Simulation Subsystem (CAMSS) and the Controller and 
Aircraft Physical Simulation Subsystem (CAPSS). 

The CAMSS contains subfunctions that allow the 
researcher to define human-interactive and scripted 
aircraft models and controller models of various 
standards, such as VDL Modes 1, 2 or 3. It also allows 
the researcher to define associated platforms and emitters 
and place these according to flight plans. Via the System 
Monitor (SM) in the CAMSS, the researcher creates 
scripts or flight plans for Autonomous Aircraft (AA) and 
Autonomous Controllers (AC) and places these in PC 
workstations. Human Interactive Aircraft (HI A) and 
Human Interactive Controllers (HIC) are also defined on 
PC workstations. As the name implies HIA’s and HIC’s 
allow researchers to interact with the simulation as pilot or 
controller respectively 

Each AA, AC, HIA and HIC is associated with a 
corresponding platform/emitter pair and this association is 
sent to the CAPSS Control Station. These become part of 
the scenario that is run. The Control Station in the 
CAPSS is used to initially define emitters with 
appropriate modulations (e.g. D8PSK). In addition, 
antenna patterns, effective radiated power (ERP), receive 
sensitivity and other physical radio parameters can be 
associated with these emitters. The CAPSS control 
station is used to create platforms that will contain these 
emitters in any combination desired. These platforms are 
given dynamic parameters based upon the type of 
platform. For example, the platform may be defined as 
fixed, ground-based, or airborne. These platforms are 
made available to the SM in the CAMSS so that the 
researcher can associate each with a particular AA, AC, 
HIA or HIC. In addition, the Control station is used to 
define platforms and emitters that are independent of the 
network defined in the CAMSS. These emitters may be 
of any type and are used to populate the scenario with 
signals that would be found in the area of interest. These 



signals may include television, radio, VHF Omni-Range 
(VOR), TACAN, Mode S, ATC voice etc. Digital Terrain 
Elevation Data (DTED) information may also be 
associated with the area of interest to allow high fidelity 
terrain and atmospheric propagation effects. These are 
loaded at the Control Station. 

Once a scenario is defined by the user and input into 
the SM and CS, the scenario is initialized. During the 
initialization process, the SM actually extracts available 
platform/emitter information from the CS and uses this 
information to associate aircraft and controller network 
models with instantiations of the available platform types. 
The SM will use flight pattern information for each 
platform that contains models under its control to place 
the platforms with initial positions and motion. The SM 
will then command the Control Station to initialize its 
scenario. The Control Station will inform the SM when it 
is finished and this will be echoed to the researcher. 

The researcher then runs the scenario by sending a 
command to the SM. Using the initial flight parameters 
and waypoints from the Control Station, the Geometry 
Relationship Processor (GRP) will fly each airborne 
platform in real time and compute platform to platform 
relationships such as pointing angles and ranges. The SM 
can send to the GRP platform flight plan updates via the 
Run Time Executive Interface (RTEI). 

Using the message scripts associated with each A A 
and AC, a model will request to send a message to a given 
receiver. This request will be sent to the RTEI in light of 
the access architecture being used by the signal to transfer 
the type of message in question. For example, if the RTEI 
receives a request to send a message that uses VDL Mode 
2, then the RTEI will decide whether the message satisfies 
the Carrier Sense Multiple Access (CSMA) criteria for 
obtaining the network. 

If the message in question does pass this test, the 
request will be forwarded on, along with the 


accompanying time of transmission from the SM, to the 
RF Environment Processor (RFEP). The RFEP will 
decide, based upon the various RF signals impinging on 
the input to the intended receiver as well as the modeled 
receiver’s input characteristics and platform relative 
geometry, whether the message of interest would be 
successfully received and demodulated. The RFEP will 
send back to the RTEI the result of the RF analysis in the 
form of a Yes or No. If an affirmative is sent, meaning 
that the message was successfully received, then a time 
delay accompanies the response. This time delay is the 
composite of RF propagation time from the transmitting 
platform to the intended receiving platform and receiver 
processing delay time. The RTEI forwards the results of 
the analysis of the requested message to the appropriate 
receiving model. The model uses the time delay 
accompanying a successful communication to decide 
when to transmit its reply, if needed. Every message 
transmitted from any of the AA, AC, HIA, or HIC models 
will undergo the same processing. These models send 
their status to the SM for logging and run time statistics 
generation and display. In addition, the individual 
subfunctions of the CAPSS store emitter and platform RF 
connectivity and relationship information for later 
retrieval by the researcher. 

Two other critical subfunctions of the CAPSS, shown 
in Figure 3, are the Run Time Control Processor (RTCP) 
and the Signal Generation Processor (SGP). The RTCP is 
used to synchronize all other CAMSS subfunctions. It 
also places the CAMSS sub functions into appropriate 
states (i.e. run, pause, initialize, etc.) and retrieves all 
extracted data when commanded by the Control Station. 
The SGP is the signal generation hardware controller. It 
controls attenuators, mixers, phase shifters and arbitrary 
waveform generators based upon simulation results in 
order to generate RF from the viewpoint of a system 
under test. 
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Figure 3. ANRS Top-Level Architecture 


2.2 ANRS Architecture Description 

The ANRS architecture is a blend of both the VAC 
and JCS products that have been successfully developed 
and delivered to NASA GRC and to the U.S. Air Force 
and Navy Avionics Test Commands, respectively. The 
VAC product was initially developed as a network 
capacity simulation tool while the JCS system was 
initially developed as an RF stimulation and test tool. The 
development of a suitable architecture to support the 
described theory of operation of the ANRS test bed 
application requires key elements including: 

• Real time software interface between network 
management tools and RF assets 

• RF Simulation capability 


• RF Stimulation of System under Test 

• Simplified Scenario generation and post test 
analysis tools 

The Top Level architecture presented in Figure 4 
illustrates the ANRS system at a higher level then that 
shown in Figure 3 in order to better describe the 
architecture from a user and top-level interface 
perspective. The proposed Full Operational Capability 
(FOC) architecture is centered on a System Under Test or 
SUT. This can be a real CNS hardware system or a virtual 
system depending on the particular test objectives desired. 
As discussed, when an experimental or operational 
avionics system is tested, the ANRS will perform as an 
RF stimulator. In the case of a virtual system, the ANRS 
provides virtual RF test capability, creating appropriate 
timing delays, signal characteristics and performance as 
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Figure 4: ANRS Top Level Architecture 


The Aircraft Control and Management System 
Simulator provides functionality that is included in 
today’s VAC system and ANRS CAMSS concept. In this 
subsystem network messages from air traffic control or 
the pilot are received, generated, acknowledged and 
monitored. This subsystem will be adaptable to many 
communications, navigation and surveillance messaging 
such as VDL, CPDLC, etc. The CAMSS will represent an 
entire network for air traffic control based on the total 
number of interactive aircraft predicted for the Los 
Angeles basin in the year 2020. The CAMSS will be 
capable of real time interaction or scripted scenarios to 
run longer test sequences and will operate with a single 
control interface through an entire network. 

The Stimulation and Operational Environment 
Simulator provides the key RF links to the SUT or a 
virtual SUT and between other communicating virtual 
players in a scenario. This subsystem, which includes the 
CAPSS, contains the capability to generate an RF 


environment with moving and fixed platforms and 
dynamic interaction between the SUT and other defined 
players in the scenario. In a virtual SUT environment, this 
subsystem will provide the geometric keys to simulate 
signal timing, fading and signal in space effects without 
generating an actual RF signal. 

The Test /Simulation Console and the Integration 
Console provide user interface to the ANRS system for 
the purpose of monitoring tests, monitoring SUT 
performance, generating Scenarios and test scripts and 
interactively conducting tests or integration experiments. 
This subsystem will provide the researcher with all 
pertinent pre and post testing data and allow manipulation 
for data reduction and test report generation. Additionally, 
support of integration activities, software debugging, 
software trace and scenario editing capabilities all reside 
in this subsystem. 







The Message Router Subsystem provides interface to 
an SUT avionics interface bus. This subsystem can be 
modified and adapted to various architectures allowing the 
monitoring of low-level bus messages and software 
performance within the SUT. Finally, the test subsystem 
will provide RF spectrum analysis tools, and various test 
equipment used to calibrate, test and monitor the RF 
performance of the RF Stimulation subsystem and/or the 
SUT. 


2.3 ANRS Key Features 

The ANRS includes several key features that will 
allow the researcher to conduct “what if’ analysis easily, 
greatly enhancing the situations that are accessible for 
study. 

First, the ANRS has an inherent capability to present 
the researcher with a realistic mix of signals. All 
networks under consideration are used in an environment 
that is filled with independent RF sources. These sources 
can be placed in the scenario by the researcher at the 
locations that correspond to the actual locale, given the 
correct physical characteristics including frequency, 
modulation, ERP, antenna patterns and content. In 
addition, the terrain characteristics of the locale being 
researched are included in the ANRS via the inclusion of 
the NIMA Digital Terrain Elevation Database. 

Second, the ANRS provides the researcher with full 
run time control over the experiment being performed. 
This allows the researcher to perturb the environment to 
see what happens. The researcher can enable and disable 
any individual emitter, change the emitter’s carrier 
frequency, ERP or messaging rate. The researcher can 
manually control individual platforms during run-time, 
disable or enable them, change their heading, climb rate 
and velocity in order to study situations that may be, at the 
very least, unsafe to implement in the real world. 

Third, the ANRS is capable of signal simulation and 
generation for almost any type of modulation imaginable, 
up to its symbol rate limitation of 10 mega-symbols per 
second, in combination with any other set of signals. This 
gives the researcher the ability to study new waveforms as 
they are being developed, before they are actually 
implemented in operational hardware, in a realistic 
environment. In addition, the signal version of the 
waveform that is implemented in the ANRS could be 


modified as the developing counterpart waveform evolves 
through the standardization process. Moreover, feedback 
from the researcher’s study results could be made 
available to the groups developing the individual 
waveforms of interest. 

Fourth, the ANRS will provide a realistic messaging 
environment that can be linked to operational 
scenarios. The use of fight plan driven scenarios that 
are coupled with CPDLC, FIS, AOC, ADS-B,TIS-B, 
and other transactions will allow RF testing using the 
mix of realistic messaging loads that emulate real 
conditions. 

3. Conclusion 

The purpose of this paper is to propose the 
development of a new and robust research tool taking 
advantage of two successfully developed 
simulation/stimulation tools. Leveraging heavily from the 
VAC and JCS strengths, the proposed ANRS system will 
give the researcher the needed information to make 
accurate and cost effective decisions relating to emerging 
aeronautical network protocol standards and their 
associated waveforms under real world conditions. 
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CNS Testing Needs 
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■ Enhancing activities on research & development of CNS 
technologies that help modernize the NAS 

■ Studying impact of data link traffic loads on future underlying 
communications infrastructure within the NAS (currently, NOT 
well understood) 

■ Current test bed system is inadequate, no real RF environment 
and lack of robust features and capabilities 

■ A need for a new, robust and cost effective test facility to allow: 

- Complex RF signal generation 

- Flexible and large scale testing of numerous CNS/ATM Concepts 

- Modeling CNS communication traffic loads of realistic operational 
scenarios (flight plan) 

- Performance evaluation of throughput and delay of aeronautical 
subnetworks under load 

- Supporting repeatable experimental trials 

- Provide an affordable approach to large scale testing 

- Include mobility related RF effects 
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NASA GRC VAC Overview 
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■ NASA GRC VAC consists of major component 
applications: 

- Human Interactive Aircraft (HIA) 

- Human Interactive Controller (HIC) 

- Autonomous Aircraft (AA) 

- Autonomous Controller (AC) 

- System Manager 


■ Software applications interface with ATN routers & 
provide a virtual aircraft/controller capability that 
emulates pilot/controller data link exchanges for up 
to 160 aircraft, using script-driven events 


■ Support Context Management (CM) & CPDLC 
messages 
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JCS Overview 
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■ JCS was built for the U.S. Air Force & Navy 
Avionics Test Commands by ViaSat, Inc to 
provide communications band test & simulation 
capability for RF spectrum. 

■ JCS architecture consists of following main 
components: 

— Control Station 

- Control Station Subsystem 

— Signal Generation Units 

- Non-AoA RF Data System 

- AoA RF Data System 
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Summary of Proposed ANRS 
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■ To develop a new, robust and cost effective Virtual RF Test Bench 
Environment/Facility requires a modular, scalable approach to allow: 

- New functions and upgrades to be added at minimum risk and cost 

- Leveraging existing architectures, functions and HW/SW capabilities of 
NASA GRC VAC and U.S. Air Force & Navy Avionics Test Commands JCS 
Systems 

- Minimize redefinition of software states and modes while maintaining 
flexibility, thus avoiding large cost through preservation of existing JCS 
software functional architecture 

■ Incremental/staged approach to development and implementation to ensure 

- Adequate system capability available at each stage of development 

- And, thus allowing ANRS operating from a Virtual RF environment through 
hardware-in-the-loop testing 

- Additional HW, SW and system capability to be integrated & demonstrated at each 
phase providing researchers with additional capability 

■ Additional waveforms added without significant impact to existing hardware 

- Customize future deliveries based on budget and schedule constraints 

■ Model Air Traffic communication traffic loads of realistic operational scenarios 
(flight plan) 

■ Performance evaluation of throughput and delay of aeronautical sub networks 
under load 

■ Support repeatable experimental trials 
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ANRS Architecture 
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■ ANRS architecture is a blend of both VAC & 
JCS 

Note: VAC was developed as a network simulation 
capacity tool, while JCS as an RF stimulation & test 
tool 

■ Key elements of ANRS architecture: 

- Real time software interface between network 
management tools & RF assets 

- RF simulation capability 

- RF stimulation of system under test (SUT) 

- Simplified scenario generation & post-test 
analysis tools 
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Desirable key features: 

■ Realistic Mix of Signals 

- Environment filled with independent RF sources 

- RF sources placed with physical characteristics including frequency, 
modulation, FRP, antenna patterns and content 

- Terrain characteristics 

■ Full Run Time Control 

- Operator intervention to instantly change environment 

- Enable or disable any individual emitters carrier frequency, ERP or message 
rate 

- Manually control movement of platforms including dynamic movement 

■ Capability to present almost any type of signal simulation 

- Up to 10 mega symbols per second in combination with any other set of signals 

- Creates realistic operational environment prior to operational status 

- Existing Waveform modifications tested prior to final implementation of 
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Summary 
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■ Proposed ANRS test facility represents a 
new, robust and cost effective research tool 
that can leverage on existing systems 

■ Implementation of emerging aeronautical 
network protocol standards and the 
associated waveforms under complex 
conditions 

■ Enhancing R&D activities in CNS 
technologies 
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